Companies such as telecommunications companies frequently purchase software, including custom software, from software development companies and other vendors. Furthermore, vendors typically release new versions of software periodically. Whenever a company considers adopting a new package or version, naturally, the company wants to be reasonably certain that the software is stable and performs the tasks that the software is supposed to perform. Hence, pre-acceptance testing is a critical part of the process of acquiring new software and new versions of software.
Typically, especially for large, custom software systems, a development version of the software will be loaded on the client system in order for the client to test the software in the environment in which the software will be used. Keeping track of identifying functions to test, assigning the testing of the functions to suitable personnel, recording the results of testing, notifying the vendor of continuing malfunctions in the software, notifying the vendor of new malfunctions in the software, receiving notification from the vendor that a malfunction has been fixed, re-testing the function, and finally closing out a function test after successful testing, can be a daunting task. When the players involved in the process are geographically separate, the task can approach gargantuan.
A database such as a MICROSOFT ACCESS database could be built to track these and other data categories and each member of the testing team could be provided with a copy of the tracking database. However, when anyone involved in the testing process updates the tracking database, a new copy of the database would have to be provided to each member of the testing team. Problems are likely to arise with keeping all the different copies of the database in sync.
For example, suppose that all the members of a testing team have the same version of a tracking database, version A. Imagine now that a client technician (tester) enters a new trouble ticket to database A, creating version A′ and e-mails the new database A′ to all the members of the testing team. Suppose that, at about the same time, a software developer fixes a software bug and enters a notation of the fix in database A, creating version A″, and sends all the members of the testing team his new A″ database. Now the members of the testing team will have two updated versions of the A database. Selection of the A′ database as the “new” database will result in the loss of the software bug fix notation while selection of the A″ database as the “new” database will result in the loss of the new trouble ticket.
It is clear that keeping multiple copies of a shared database consistent between geographically diverse users is problematic. Hence, a need exists in the art to have a single shared database accessible by multiple geographically diverse users.